NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/dcom/modems-part1/5036

Text File | 1996-08-05 | 3.4 KB | 69 lines

Newsgroups: comp.dcom.modems
Path: news.uunet.ca!gts!bokonon!stephen
From: [e-mail] (Stephen M. Dunn)
Subject: Re: Shouldn't avg. file transfers speed match modem speed?
Organization: United System Solutions Inc.
Date: Wed, 21 Feb 1996 05:12:45 GMT
Message-ID: <[e-mail]>
References: <4fmmhi$[e-mail]> <[e-mail]> <[e-mail]>

In article <[e-mail]> Bob Uhrick <[e-mail]> writes:
$Ernesto Laban wrote:
$> You get two things mixed up. 14k4 means 14.400 BITS per second.
$> The download value you mentioned is kBYTES per second.
$> 1 byte is 8 bits. so if you divide 14,4/8=1.8 kByte per second.
$
$Correct me if I'm wrong, but I've always thought modems transmit 10 bits for
$each byte.  8 bits for the character, plus 1 parity bit and 1 stop bit?

   Not for reasonably modern modulations.

   I know V.32 and up are synchronous - that is, there are no start
or stop bits exchanged between modems - and I think that goes as far
down as V.22.  There are no start or stop bits around each character
in synchronous communications; there's just a stream of bits.

   Now, the link between the PC/terminal/printer/whatever and the
modem is usually asynchronous - eight data bits, one start bit, one
stop bit being the most common.

   If you're using an error-control protocol which takes advantage
of the synchronous nature of the link (e.g. MNP3 or a level built on
it, or LAP-M), you can get additional throughput even without data
compression.  Let's say you have a 9600 bps connection between two
modems.  At 10 bits per character, that's 960 cps.  At eight
bits per character, that's 1200 cps; not a bad improvement.
An error-control protocol will generally form your data into
packets, and introduce a little overhead on the packets for
headers, trailers, error detection codes, whatever - but they
will also strip off the start and stop bits, so that you're
getting 1200 cps of throughput, minus the overhead in each
packet.  Usually, what's left is 10-15% better than the 960
cps you started with.

   To get this benefit, though, you have to have your computer
talk to the modem at a higher data rate.  If you talk 9600 bps
to the modem, that's 960 cps - and if you can only feed the
modem 960 characters each second, that's all you'll get out of
the other end.  If, on the other hand, you talk to the modem
at 19 200 bps, that's 1920 characters each second, and now
the 1100 or so cps that's left over after protocol overhead is
the throughput you'll get (assuming the other end is also
talking to its modem at more than 9600 bps).  Again, this
does _not_ involve data compression; compression can add even
more to the throughput you get, depending on the nature of the
data.

   It's important to note that if you're going to be talking to
the modem faster than it can actually transmit data, you need
a way of having the modem say "Whoa, stop for a sec while I
catch up."  That's called flow control.  Without it, it's like
pouring water through a narrow hose using a funnel - and not
looking to see if the funnel's about to overflow.  You'll get
spillage.
--
[e-mail]               ...!{xrtll,gts.org}!bokonon!stephen
----------------------------------------------------------------------------
Stephen M. Dunn, CNE, ACE, Sr. Systems Analyst, United System Solutions Inc.
104 Carnforth Road, Toronto, ON, Canada M4A 2K7          [phone] x251